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FIELD OF THE INVENTION 

The present invention relates generally to computer systems, and in 
particular, relates to computer systems' basic input output system (BIOS). 

BACKGROUND INFORMATION 



The BIOS includes a collection of executable programs and data to 
initialize other components of a computer system. Upon turning on (or alternatively 
resetting) the computer system, the computer system executes the BIOS from 
nonvolatile memory such as read-only memory (ROM) chip(s), or equivalent. In 
1 5 many computer systems, the BIOS loads all or part of the operating system, which is 
usually stored on the computer system's hard disk. Alternatively, the operating 
system may be loaded from a compact disc (CD) ROM or a floppy disk. The loaded 
operating system may subsequently call a BIOS routine or component. 

The BIOS (also referred to herein as firmware) in a pre-memory 
20 execution environment is usually tightly bound object code that is built for a specific 
configuration or system design (also referred to herein as a platform). That is, 
different platforms typically have different BIOSs. More particularly, the BIOS 
typically includes code (also referred to herein as firmware modules) for providing 
certain functions or services, which in turn may depend on the platform. For 
25 example, the firmware module for a particular service may be different for a platform 
with a Pentium III® processor compared to one with a Pentium IV® processor. 
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Thus, a BIOS vendor will typically develop several BIOSs to support various 
platforms, which undesirably increases costs in testing, maintaining and 
documenting the multiple BIOSs. 

Further, the traditional development process requires software 
developers to compile and link their firmware module with the main firmware 
executable code. Additionally, the process often requires the software developer to 
customize the firmware module for each vendor's main firmware executable code. 
This undesirable process requires the developer to test the firmware module for 
proper operation in each firmware environment, which tends to increase 
development time and costs. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Non-limiting and non-exhaustive embodiments of the present invention 
are described with reference to the following figures, wherein like reference 
numerals refer to like parts throughout the various views unless otherwise specified. 

Figure 1 is a block diagram illustrating a computer system having a 
modular BIOS, according to one embodiment of the present invention. 

Figure 2 is a diagram illustrating a modular BIOS, according to one 
embodiment of the present invention. 

Figure 3 is a diagram illustrating communication links between 
modules of a modular BIOS according to one embodiment of the present invention. 

Figures 4A and 4B are flow diagrams illustrating a basic initialization 
operation of a modular BIOS according to one embodiment of the present invention. 

Figure 5 is a diagram illustrating a data structure for tracking dispatch 
of firmware modules, according to one embodiment of the present invention. 

Figure 6 is a block diagram illustrating components of a firmware 
module, according to one embodiment of the present invention. 

Figures 7A and 7B are diagrams respectively illustrating import and 
export tables, according to one embodiment of the present invention. 

Figure 8 is a flow diagram illustrating a process for linking firmware 
modules in the BIOS, according to one embodiment of the present invention. 

Figure 9 is a flow diagram illustrating a module call operation, 
according to one embodiment of the present invention. 

Figure 10 is a flow diagram illustrating a daisy chaining operation, 
according to one embodiment of the present invention. 

Figure 1 1 is a diagram illustrating a filter module, according to one 
embodiment of the present invention. 
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DETAILED DESCRIPTION OF THE ILLUSTRATED EMBODIMENTS 

Figure 1 illustrates a computer system 100, in accordance with one 
embodiment of the present invention. Computer system 100 includes a 
processor 103, a nonvolatile memory 105, a main memory 107, devices 109-1 
through 109-N, and a bus 111. In addition, computer system 100 includes a 
modular BIOS 120 stored in nonvolatile memory 105. 

Processor 1 03 may be a conventional microprocessor, such as, but 
not limited to, an Intel x86 or Pentium family microprocessor, a Motorola family 
microprocessor, and the like. Nonvolatile memory 105 can be implemented in 
several ways. For example, nonvolatile memory 105 can implemented using 
devices that include, but are not limited to, erasable programmable read-only 
memory (EPROM) devices, electrically erasable programmable read-only memory 
(EEPROM) devices, Flash memory devices, and the like. Main memory 107 can be 
implemented using devices that include, but are not limited to, dynamic random 
access memory (DRAM), static random access memory (SRAM), and the like. 
Devices 109-1 to 109-N are devices typically used in a computer system such as, 
but are not limited to, a display, monitor, keyboard, hard disk drive, CD ROM drive, 
network interface card (NIC), sound card, printer, scanner, pointing device (e.g., 
mouse, trackball, touch pad) and the like. Main memory 107, nonvolatile 
memory 105, processor 1 03, and device(s) 109-1 to 109-N are all coupled to 
bus 111. 

It is appreciated that computer system 100 is one example of many 
possible computer systems that have different architectures. For example, 
computer systems that utilize the Microsoft Windows operating system in 
combination with Intel microprocessors often have multiple buses, one of which may 
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be considered a peripheral bus. Network computers may also be considered as 
computer systems that may be used with the present invention. In addition, 
handheld or palmtop computers, which are sometimes referred to as personal digital 
assistants (PDAs), may also be considered as computer systems that may be used 
5 with the present invention. A typical computer system will usually include at least a 
processor 103, a main memory 107, a nonvolatile memory 105, and a bus 111. 

It will also be appreciated that in one embodiment, computer 
system 100 is controlled by operating system software that includes a file 
u management system, such as a disk operating system, which is part of the 

S 10 operating system software. For example, one embodiment of the present invention 

v.. 3 

y utilizes Microsoft Windows as the operating system for computer system 100. In 

f another embodiment, other operating systems include, but are not limited to, an 

'Saw? 

m Apple Macintosh® operating system, a Microsoft Windows® operating system, a 

S Unix operating system, a Palm® operating system, and the like may be used in 

ft 15 accordance with teachings of the present invention. In general, the particular 
O operating system that is utilized in computer system 100 will be based on at least in 

part upon the specific architecture, chips or chipsets that are utilized in computer 

system 100. 

Figure 2 illustrates BIOS 120 (Figure 1) residing in nonvolatile 
20 memory 105 (Figure 1), according to one embodiment of the present invention. In 
this embodiment, nonvolatile memory 105 is divided into blocks 201-204, each 
having a size of 64KBytes. In this embodiment, block 201 is the boot block. Boot 
block 201 includes a reset vector 208, a core 210, and firmware modules 212-1 
to212-M. Blocks 202, 203, and 204 are used to store other components of 
25 BIOS 120 and to provide some non-volatile storage during execution of BIOS 120. 

The Reset vector 208 is the first memory location read by 
processor 103 (Figure 1) after a power on or reset. In one embodiment, reset 
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vector 208 causes processor 103 to execute instructions commonly referred to as a 
POST (power on self test).ln one embodiment, the operation flow begins to execute 
core 210. Core 210 serves as a scheduler or dispatcher for firmware modules 212-1 
to212-M. Core 210 also contains instructions for a core set of services. These 
5 core services include, but are not limited to, location of platform variables, 
management of the boot mode, common tasks such as copying and zeroing 
memory. Each firmware module 212-1 to212-M contains instructions associated 
with a service for one or more components that may be included in computer 
system 100. In accordance with the present invention, each firmware module has a 
10 common interface component for interfacing with core 210. In addition, a firmware 
W module may include a common interface for interfacing with another firmware 

module. As will be further described below, these features allow for a BIOS that 
includes core 210 and firmware modules 212-1 to 212-M (i.e., a modular BIOS) to 
be interoperable with multiple platforms in a manner that is somewhat analogous to 
15 how an operating system and drivers allow a computer system to interoperate with 
multiple peripheral devices. 

Figure 3 further illustrates functional interconnections between 
core 210 and firmware modules 212-1 to 212-M and between the firmware modules 
themselves. In one embodiment, each firmware module 212-1 to 212-M includes a 
20 common core/module interface (not shown) for interfacing with core 210; and a 
common module/module interface (not shown) for interfacing with other firmware 
modules. For example, core 210 can interface with firmware module 212-1 as 
indicated by a doubled-headed arrow 301, as well as firmware modules 212-2 to 
212-M, using the common core/module interface. In addition, firmware 
25 module 212-1 can interface with firmware module 212-2 as indicated by a double- 
headed arrow 303, using the common module/module interface. Although not 
shown in Figure 3, other firmware modules 212-3 to 212-M may also be configured 
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with the common module/module interface to interface with another firmware 
module. These components are described further below in conjunction with 
Figure 6. 

Figure 4A illustrates a basic initialization process performed using 
5 modular BIOS 120 (Figure 1), according to one embodiment of the present 
invention. In this embodiment, modular BIOS 120 has been loaded into nonvolatile 
memory 105 (Figure 1) after undergoing a build process, which serves to compile 
and link core 210 and firmware modules 212-1 to 212-M in boot block 201 
(Figure 2). Referring to Figures 1,2 and 4, modular BIOS 120 performs this 
1 0 embodiment of this process as follows. 

In a block 402, computer system 100 is turned on or reset. In 
particular, when computer 100 is turned on, processor 103 begins executing 
BIOS 120. In one embodiment, a user can actuate a switch to provide power to or 
reset computer system 100. In many embodiments, a user can also reset the 
15 computer system 100 via a user interface (e.g., via a menu selection) provided by 
the operating system running on computer system 100. 

In a block 406, the reset vector is executed. In this embodiment, upon 
power up (or reset) processor 103 begins executing reset vector 208, which as 
previously described is the first instruction of BIOS 120. In one embodiment, reset 
20 vector 208 typically provides the first instruction of the POST process. In some 
embodiments, the POST is not executed during a reset. 

In a block 410, the firmware modules are then initialized. In one 
embodiment, processor 103 executes core 201. In this embodiment, core 201 
determines the requirements configuration of firmware modules 212-1 to 212-M 
25 appropriate to run. Each module, in turn, examines the platform to determine if the 
hardware it initializes is present for the platform in which BIOS 120 is installed. 
Block 410 is described in more detail below in conjunction with Figure 4B. 
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In a block 414, the memory is initialized. In this embodiment, during 
processor initialization of firmware modules 212-1 to 212-M, processor execution of 
one or more of modules 212-1 to 212-M will initialize main memory 107. 

In a block 418, the rest of BIOS 120 is received and executed. For 
5 example, after main memory is initialized in block 414, processor 103 can retrieve 
add-on BIOS components (i.e., BIOS extensions) that may reside in other external 
memory devices (e.g., additional EEPROM or Flash block boot components). 
BIOS 120 can then complete initialization or allow the operating system to complete 
initialization. 

10 Figure 4B illustrates block 410 (Figure 4A) in more detail, according to 

W one embodiment of the present invention. Referring to Figures 1 , 3 and 4B, this 

*P embodiment of block 4 1 0 is performed as follows. 

m 

In a block 424, firmware modules 212-1 to 212-M are examined to 
S determine the order of which of firmware modules 21 2-1 to 21 2-M are required to be 

5 15 dispatched by the core 201 to allow computer system 100 to operate properly. In 
one embodiment, core 210 includes instructions to check a resource list (described 
below in conjunction with Figure 6) of firmware modules 212-1 to 212-M to 
determine which of these firmware modules are required. 

In a block 428, the execution of the required firmware modules is 
20 scheduled. In one embodiment, core 210 schedules the execution of the required 
firmware modules. For example, core 210 can schedule firmware module execution 
based on the requirements of each firmware module as determined in block 424 
above. In one exemplary embodiment, core 210 could schedule firmware modules 
in the following order: central processor unit (CPU) I/O (input/output) services, PCI 
25 configuration access services, ICH (I/O controller hub) component platform 
initialization services, SMBus (System Management Bus) protocol access services, 
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MCH (memory controller hub) component platform initialization services, etc., which 
are typically needed early in the initialization process. 

In a block 432, the required firmware modules are dispatched (i.e., 
executed by processor 1 03). In one embodiment, core 210 can use a register of 
5 processor 103 to store a bit array that indicates which firmware modules are to be 
dispatched. One exemplary embodiment of this bit array is described further below 
in conjunction with Figure 5. 

Figure 5 illustrates a data structure for tracking dispatch of firmware 
modules, according to one embodiment of the present invention. In this 
10 embodiment, the data structure is a bit array 500 that can be stored using a single 
64-bit register of processor 103 (Figure 1), for a maximum of sixty-four firmware 
modules in BIOS 120. Each bit of bit array 500 is mapped to a corresponding one 
of firmware modules 212-1 to 212-M. More particularly, in the embodiment of 
W Figure 5, a bit 512-1 of bit array 500 corresponds to firmware module 212-1, as 

M 15 indicated by a dashed line 514-1; a bit 512-2 corresponds to firmware module 212-2 

pass 

f| as indicated by a dashed line 514-2; ...; and a bit512-M corresponds to firmware 

module 212-M as indicated by a dashed line 514-M. In this embodiment, when a bit 
of bit array 500 is set to a one, then the corresponding firmware module has been 
dispatched. 

20 Figure 6 illustrates components of an exemplary firmware module 212, 

according to one embodiment of the present invention. That is, some embodiments 
of firmware modules 212-1 to 212-M (Figure 2) have the same components as 
firmware module 212. In this embodiment, firmware module 212 includes a global 
unique identifier (GUID)601, a resource list 603, an import table 605, an export 

25 table 607, services 609-1 to 609-L, a service interface 611 and an inter-module 
interface 613. In some embodiments, firmware module 212 is organized as a 
header and an executable image. The header can include resource list 603, import 
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table 605, export table 607 and a list of services (not shown) provided by firmware 
module 212. The executable image includes the code for each service. These 
components of firmware module 212 are described further below. 

GUID601 uniquely identifies firmware module 212. In one 
embodiment, GUID 601 is a sixteen byte number generated using the Wired For 
Manageability Baseline Version 2.0 standard when firmware module 212 is created. 

Resource list 603 is a list of resources needed by firmware 
module 212 to properly function. For example, resource list 603 may include the 
GUIDs of other firmware modules, services or the GUIDs of module-to-module 
interfaces provided by other firmware modules. Resource list 603 is generated 
when firmware module 212 is created. 

Import table 605 lists the firmware modules and/or services imported 
or called by firmware module 212. In this exemplary embodiment, firmware 
module 212, while executing, may call one or more services during the course of 
execution. The exemplary embodiment of import table 605 in Figure 6 shows 
several services that can be called by firmware module 212, listed as l_Service-1, 
l_Service-2, and so on. One embodiment of import table 605 is described further 
below in conjunction with Figure 7A. 

Export table 607 lists the firmware modules and/or services that can 
be called by other firmware modules. In this embodiment, export table 607 is filled 
during the build process (mentioned above in conjunction with Figure 4A). For 
example, during a build process, the process selects a firmware module and 
examines all of the remaining firmware modules to determine which of these 
firmware modules calls the selected firmware module by examining the remaining 
firmware module's import table. For each firmware module consuming this module's 
export interface, the consuming firmware module's import table is then modified to 
include the correct physical address of the exported interface. The build process 

10 



Attorney Docket: 42390.P09143 



then selects another firmware module and performs another pass through the 
firmware modules, and so on until all of the import tables of all of the firmware 
modules have been filled. One embodiment of the build process is described further 
below in conjunction with Figure 8. 

As mentioned above, firmware module 212 includes service 609-1 to 
service 609-L A firmware module may have only one service in other 
embodiments. In this embodiment, each service also has a GUID that uniquely 
identifies the service. In some embodiments, multiple firmware modules may 
perform the same service and, thus, have the same GUID for that service. Although 
these services may have the same GUID and perform the same function, they are 
different from each other in that they are configured for a particular environment or 
hardware configuration. In such a case, the service that is actually executed is the 
one configured for the platform's environment or hardware. 

Service interface 611 serves as the interface of firmware module 212 
to core 210 (Figure 2). For example, for core 210 to make a call to firmware 
module 212, core 210 would execute an instruction that contains information such 
as the physical address of firmware module 212 and a return address to core 210. 
Service interface 611 is a standard interface for all firmware modules so that 
core 210 can call any firmware module (from any vendor). Thus, core 210 can pass 
parameters, etc., in a single format to any firmware module, which in turn will be 
properly operated on by that firmware module. 

Inter-module interface 613 serves as the interface of firmware 
module 212 to another firmware module. For example, for firmware module 212 to 
make a call to another firmware module, firmware module 212 would execute an 
instruction that contains information such as the physical address of the other 
firmware module and a return address of firmware module 212 or, in some 
embodiments, of core 210 in a daisy-chaining process (described further below in 
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conjunction with Figure 8). In some embodiments, interfaces 611 and 613 are the 
same. 

Figure 7A illustrates import table 605, according to one embodiment of 
the present invention. As shown by Figure 7A, exemplary import table 605 contains 
one or more services (i.e., LService-1 to l_Service-X) that firmware module 212 
may call while it is executing. In this embodiment, each l_Service has a name, a set 
of flags, and an address. In one embodiment, the name is the GUID for the 
^Service. The flags are bits that are used to indicate whether predetermined 
configuration attributes have been set (e.g., daisy-chaining, Stub interface, Internal 



10 interface, etc.). The address is a physical memory address representing the start 



address of firmware module to be called summed with the offset of the service from 
the start address. This entry of import table 605 is filled during the build process. 
For example, the build tool or application can determine the start address of 
firmware module to be called and add this address to the offset, which the build tool 
1 5 can retrieve from the export table of the firmware module to be called, 
ry Figure 7B illustrates export table 607, according to one embodiment of 

the present invention. As shown by Figure 7B, exemplary export table 607 contains 
one or more services (i.e., E_Service-1 to E_Service-Y). In this embodiment, each 
E_Service has a name, a set of flags, and an offset. In one embodiment, as in an 
20 LService (Figure 7A), the name is a GUID and the flags are bits that are used to 
indicate whether predetermined configuration attributes have been set (e.g., daisy- 
chaining, loopback interfaces, etc.). The address is a physical memory address 
representing the offset of the E_Service from the start address of firmware 
module 212. This entry of export table 607 is filled by the compiling and linking of 
25 firmware module 212. This offset is available to the build tool (mentioned above in 
conjunction with Figure 7A) during the build process to fill import table 605. 
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Figure 8 illustrates a build process, according to one embodiment of 
the present invention. In one embodiment, the build process is performed by the 
BIOS vendor using a build tool that serves in effect to compile and link the firmware 

modules and core of the BIOS. 
5 In a block 801, firmware modules to be included in the BIOS are 

selected. In one embodiment, the BIOS vendor gathers firmware modules from 
various sources. This feature advantageously provides flexibility, and can help the 
BIOS vendor avoid the need to develop its own firmware module or modules. In 
5 addition, once a firmware module has been tested and verified as compliant, the 

5 1 0 testing requirements for the BIOS vendor are simplified since the firmware module is 
1 demonstrated to be reliable. Still further, this feature can allow a BIOS vendor to 
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quickly provide BIOSs for new platforms because very likely only a small portion of 
the BIOS code will need to be developed. These selected firmware modules are 
then placed in a file and operated on by a build tool. 
15 In a block 805, the service calls by each selected firmware module are 

S3 retrieved. In one embodiment, for each firmware module, the build tool gets the 

service calls from the firmware module's import table. For example, in a first pass, 
the build tool examines the import table of a first firmware module (selected in 
block 801) and gets the start address of all of the firmware modules that the first 
20 firmware module may call. The build tool may then examine the import table of a 
second firmware module to get the start addresses of all of the firmware modules 
that the second firmware module may call, and so on. 

In a block 809, the physical addresses of each called service or 
firmware module is determined. In one embodiment, the build tool examines the 
25 export table of the called firmware modules. As previously described, the export 
table of each firmware module includes the offset of each service that firmware 
module provides. Thus, the build tool can determine the physical address of a 
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called service by adding the offset of the called service and the start address of the 
firmware module containing the service. 

In a block 813, the physical addresses of the called service or firmware 
module is stored. In one embodiment, the build tool stores these physical 
5 addresses in the import table of the appropriate firmware modules. For example, in 
one embodiment, the build tool may make a first pass through the firmware modules 
by performing blocks 805, 809 and 813 to fill the import table of a first firmware 
module. The build tool may then make a second pass through all of the firmware 
modules by performing blocks 805, 809 and 813 to fill the import table of a second 
10 firmware module, and so on until the import tables of all of the firmware modules 
selected in block 801 have been filled. 

Figure 9 illustrates a call operation, according to one embodiment of 
the present invention. A calling agent (e.g., core 210 or one of firmware 
modules 212-1 to 212-M of Figure 2), while executing, may make a call to a service 
15 of another of firmware modules 212-1 to 212-M. In response, this called service 
would then be executed, with the operational flow returning to the calling agent 
when the called service completes execution. One embodiment of this call 
operation is described below. 

In a block 902, the physical address of the firmware module or service 
20 to be called is determined. In one embodiment, the calling agent looks up the 
physical address of the firmware module or service in a table maintained by the 
calling agent. For example, a calling firmware module would look up the physical 
address in its import table. Core 210 has a table of the physical addresses of all of 
the firmware modules and services that was filled during the build process (see 
25 Figure 8). Core 210 would look up the physical address of the called service in this 
table. 
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In a block 906, the calling agent saves the return address (i.e., the 
address to which execution returns after execution of the called service) so that the 
operational flow can return to the point it left off during execution of the calling 
agent. In one embodiment, the return address is saved in a register of 
processor 103 (Figure 1). Thus, in one embodiment, only two registers of 
processor 103 are used during the pre-memory execution of BIOS 120 (Figure 2); 
i.e., one for bit array 500 and one for the return address. Thus, this embodiment 
advantageously frees the other registers of processor 103 for other purposes. In 
other embodiments, block 906 may be performed before block 902. 

In a block 910, the called service is executed. More particularly, in this 
embodiment, the calling agent causes processor 103 (Figure 1) to execute the 
instruction stored at the physical address found in block 902 (i.e., the beginning 
instruction of the called service). After execution of the called service is completed, 
a block 914 is performed in which the operational flow returns to the calling agent 
using the return address that was saved in block 906. 

Figure 10 illustrates a daisy chaining operation, according to one 
embodiment of the present invention. This daisy chaining feature allows BIOS 120 
(Figure 1) to be executed without specific knowledge of the hardware present in the 
platform. For example, the daisy chaining feature is advantageously used when 
BIOS 120 may be used in multiple platforms. In particular, BIOS 120 would include 
multiple firmware modules, some of which are designed for a particular hardware 
component that may or may not be present in the platform. For example, the 
platform vendor may select on of several different hardware components that 
perform the same function, each having a firmware module to operate the hardware 
component. In this embodiment, the firmware modules for such hardware 
components have the same GUID identifying the service that operates the hardware 
component. The firmware module corresponding to the actual hardware component 
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present in the platform must be executed when such GUID service is called. Daisy 
chaining advantageously allows the firmware modules themselves determine which 
firmware module should be executed for the hardware component present in the 
platform. 

One embodiment of the daisy chaining operation is described below 
using exemplary firmware modules 212A, 212B, and212C. In this example, the 
import and export tables of firmware modules 212A-212C have a "daisy chain" flag 
(see Figures 7A and 7B) set for the particular service corresponding to the "multi- 
hardware component" GUID. During the build process, when the build tool first finds 
a firmware module that has the daisy chain flag set (i.e., firmware module 212A in 
this example), the build tool then checks the import tables of the remaining firmware 
modules until it finds a service having the same GUID. In this example, the next 
firmware module is firmware module 212B. The build tool stores the physical 
address of that service in a variable (variable PNEXT in this example) of firmware 
module 21 2A. The build tool repeats this process to find the physical address of a 
next firmware module (i.e., firmware module 21 2C in this example) to daisy chain to 
firmware module 212B. In this example, only firmware modules 21 2A-212C have 
services with the same GUID, so the build tool will not find a physical address to 
load in variable PNEXT of firmware module 212C. Thus, variable PNEXT is set to 
zero (i.e., null) in this example. Other services may have a number of daisy-chained 
firmware modules that is different from that of this example (i.e., any number greater 
than or equal to two). One embodiment of daisy chaining operates as follows. 

In a block 1001 A, while firmware module 212A is executing, firmware 
module 21 2A determines whether the hardware component the service is designed 
to operate with is present in the platform. In one embodiment, firmware 
module 21 2A performs this operation by checking a configuration register 
maintained in hardware. 
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If the hardware component is present, then firmware module 212A 
continues executing to perform the called service in a block 1003A. After firmware 
module 21 2A completes execution, the operational flow returns to the calling agent 
inablock 1005A. 

5 However, if in block 1001 A the hardware component is not present in 

the platform, the operational flow proceeds to a block 1007A. In block 1007A, the 
process determines whether there is a next firmware module in the daisy chain. In 
one embodiment, firmware module 21 2A checks variable PNEXT to see if it holds a 
physical address. For example, firmware module 212A can test if variable PNEXT is 
10 null (thereby indicating there is not a next link in the daisy chain). 

If variable PNEXT is null, the operational flow proceeds to a 
block 1009A in which firmware module 212A indicates that an error has occurred. In 
one embodiment, firmware module 21 2A causes an error message to be displayed 

via a display or monitor (not shown) of computer system 100 (Figure 1). The 

Ms 

\& 1 5 operational flow then proceeds to block 1005A (described above), 
jff In contrast, if variable PNEXT is not null (i.e., holds a physical address 

of the next firmware module in the daisy chain), the operational flow jumps to the 
physical address loaded in variable PNEXT in a block 1011 A to execute the next 
firmware module in the daisy chain. In this exemplary embodiment, the next 
20 firmware module is firmware module 21 2B. 

Firmware module 212B operates in essentially the same manner as 
firmware module 21 2A described above. That is, the description above for firmware 
module 21 2A applies equally well to firmware module 21 2B by replacing the letter 
"A" appended to the reference numbers with the letter "B". 
25 Firmware module 212C also operates in essentially the same manner 

as firmware module 212A. However, since firmware module 21 2C is the last link of 
the daisy chain in this exemplary embodiment, variable PNEXT of firmware 
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module 21 2C should be set to NULL during the build process. Thus, block 101 1C 
would not be performed in normal operation. 

Figure 11 illustrates a filter module 1100 for use in BIOS 120 
(Figure 1), according to one embodiment of the present invention. Filter 
5 module 1100 is platform specific and can be advantageously used in platforms 
having two or hardware components (having different GUIDs) that perform similar 
functions. Such a platform may be designed so that a particular one of these 
hardware components is used, depending on the calling module and/or the called 
Q service. In this embodiment, a filter module for a different platform would have the 

•jK!S| 

5 10 sameGUID. 

Referring again to Figure 11, filter module 110 is operatively 



interconnected with other firmware modules of BIOS 120 (Figure 1) as follows. 
Filter module 1100 has an interface 1 102 that can be called by firmware 
modules 1104-1 to 1104-R. Although at least three "calling" firmware modules are 
J: 15 shown in Figure 1 1 , in some embodiments of BIOS 120, there can be as little as one 
rtJ calling firmware module for use with filter module 1100. Filter module 1100 is 

configured by the platform vendor to be able to call firmware modules 1106-1 to 
1 106-S. Although at least three "called" firmware modules are shown, there can be 
as few as one "called" firmware module for use with filter module 1100 in other 
20 embodiments of BIOS 120. 

In operation, firmware modules 1104-1 to 1104-R can call a service to 
be provided by one of firmware modules 1106-1 to 1 106-S. Firmware 
modules 1 104-1 to 1 104-R do not need to know the GUIDs of the services provided 
by firmware modules 1 106-1 to 1 106-S. Rather, firmware modules 1 104-1 
25 to 1 104-R are configured with the GUID of filter module 1 100, which these "calling" 
firmware modules use to call filter module 1 100. Filter module 1 100 processes each 
received call and in turn calls the appropriate one of "service" firmware 
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modules 1106-1 to 1106-S, which can depend on the configuration of the platform, 
the "calling" firmware module and/or the "service" firmware module. 

For example, the hardware components may be System Management 
Bus (SMBus) controllers. One platform may be configured to use a single SMBus 
controller while another platform may be configured to use one SMBus controller to 
access processor 103 (Figure 1) and another SMBus controller to access memory 
modules. In this embodiment, the "calling" firmware modules 1104-1 to 1104-R are 
configured to simply call an SMBus controller service by using the GUID of filter 
module 1100, without having to have knowledge of the multiple SMBus controller 
services. The platform specific filter module 1 100 is configured to interpret calls to 
its GUID and, in response, call the appropriate SMBus controller service of firmware 
modules 1106-1 to 1106-S. Thus in this example, the process of calling an 
appropriate one of the various available SMBus services is transparent to "calling" 
firmware modules 1104-1 to 1104-R, which only have to be configured to call filter 
module 1100. As a result, only filter module 1100 needs to be platform specific, 
while firmware modules 1104-1 to 1104-R and firmware modules 1106-1 to 1106-S 
can be non-platform specific for use in various platforms. 

Embodiments of a system and method for linking firmware modules in 
a pre-memory environment are described herein. In the following description, 
numerous specific details provide a thorough understanding of embodiments of the 
invention. One skilled in the relevant art will recognize, however, that the invention 
can be practiced without one or more of the specific details, or with other methods, 
components, materials, etc. In other instances, well-known structures, materials, or 
operations are not shown or described in detail to avoid obscuring aspects of the 
invention. 

Reference throughout this specification to "one embodiment" or "an 
embodiment" means that a particular feature, structure, or characteristic described 
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in connection with the embodiment is included in at least one embodiment of the 
present invention. Thus, the appearances of the phrases "in one embodiment" or "in 
an embodiment" in various places throughout this specification are not necessarily 
all referring to the same embodiment. Furthermore, the particular features, 
5 structures, or characteristics may be combined in any suitable manner in one or 
more embodiments. 

In the following description, for purposes of explanation, specific 
nomenclature may be set forth to provide a thorough understanding of the present 
invention. However, it will be apparent to one skilled in the art after reading the 
10 description that these specific details are not required in order to practice the 
present invention. 

Some portions of the detailed descriptions that follow may be 
presented in terms of algorithms and symbolic representations of operations on 
information stored in a computer memory. These algorithmic descriptions and 

15 representations can be used by those skilled in the art to convey the substance of 
their work to others skilled in the art. An algorithm is here, and generally, conceived 
to be a self-consistent sequence of steps or operations leading to a desired result. 
These steps or operations may require physical manipulations of physical quantities. 
Usually, though not necessarily, these quantities take the form of electrical, 

20 magnetic or electromagnetic signals capable of being stored, transferred, combined, 
compared or otherwise manipulated. These signals are commonly referred to here, 
and generally, as bits, bytes, words, values, elements, symbols, characters, terms, 
numbers or the like. 

Unless specifically stated otherwise, terms such as "processing", 

25 "computing", "calculating", "determining", "displaying" or the like refer to actions and 
processes of a computer system, or other similar electronic computing device. In 
particular, these actions and processes manipulate and transform data represented 
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as physical quantities (as described above) within the computer system's registers 
and memories into other data similarly represented as physical quantities with within 
the computer system's memories or registers or other information storage, 
transmission or display devices. 

The present invention also relates to one or more apparatus for 
performing the operations described herein. An apparatus may be specially 
constructed for the required purposes, or include a general-purpose computer 
selectively activated or configured by a computer program stored in the computer. 
Such a computer program may be stored in a computer readable storage medium 
such as, but not limited to, any type of disk including floppy disks, optical disks, 
compact disks (CDs) and magnetic-optical disks. Other storage mediums include: 
read only memories (ROMs) including erasable and electrically erasable 
programmable ROMs (EPROMs and EEPROMs); random access memories (RAMs) 
including static and dynamic RAMs; and magnetic or optical cards. 

Algorithms and displays presented herein are not inherently related to 
any particular computer or other apparatus unless specifically stated otherwise. 
Various general-purpose systems, as well as specialized apparatus, may be used 
with programs in accordance with the teachings herein. In addition, the present 
invention is not described with reference to a particular programming language. In 
light of the present disclosure, those skilled in the art can use a variety of 
programming languages to implement the teachings of the present disclosure 
without undue experimentation. 

The above description of illustrated embodiments of the invention, 
including what is described in the Abstract, is not intended to be exhaustive or to 
limit the invention to the precise forms disclosed. While specific embodiments of, 
and examples for, the invention are described herein for illustrative purposes, 
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various equivalent modifications are possible within the scope of the invention, as 
those skilled in the relevant art will recognize. 

These modifications can be made to the invention in light of the above 
detailed description. The terms used in the following claims should not be 
construed to limit the invention to the specific embodiments disclosed in the 
specification and the claims. Rather, the scope of the invention is to be determined 
entirely by the following claims, which are to be construed in accordance with 
established doctrines of claim interpretation. 
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